In the Non-Patent Document 1 as given below, for instance, a technique is disclosed, according to which a mobile node (MN) associates and registers a care-of address (CoA) and a home address (HoA) to its own home agent (HA) by using the mobile IPv6 (MIPv6). By this technique, the reachability of the mobile node can be accomplished even in case the mobile node is located at a location separated away from the home network.
On the other hand, when there are provided portable electronic devices where a plurality of network interfaces are incorporated, a mobile node has a function to register a plurality of CoA's (multiple CoA) to a predetermined home agent address. On this registration method, discussion is made in the Working Group of Monami6 (Mobile Nodes and Multiple Interfaces in IPv6) of IETF (Internet Engineering Task Force).
Also, in the Non-Patent Document 2 as given below, a technique is disclosed, according to which the multiple CoA can be registered by introducing Binding Unique Identification (BID), i.e. an identification number to identify a plurality of bindings to a single HoA. BID is assigned to an interface or to a CoA associated with a certain home address (HoA) of the mobile node. Therefore, HoA is associated with the mobile node, and BID identifies each binding registered by the mobile node. The mobile node notifies BID to its own home agent by Binding Update (BU), and the home agent records BID in a binding cache.
Further, in the Non-Patent Document 3 as given below; it is described that the routing of a traffic flow can be selectively performed by using a plurality of CoA's when the mobile node and/or the router set up preference information to the home agent. Each traffic flow is identified by unique flow identification information (FID), and the mobile node and/or the router can select CoA, to which the routing of a specific traffic flow should be made, and the FID is associated with a suitable BID, and this can be registered to HA.
However, the setting of the preference relating to the traffic flow route is not always made by the mobile node and/or the router. Under a certain circumstance, operation to select a suitable route of the traffic flow is carried out by a service provider that performs communication with the mobile node and/or the router. For instance, it is supposed here that a user of the mobile node receives “i mode” (registered trademark) from the service provider. The traffic of “i mode” (registered trademark) is a traffic flow restricted within a domain, and this traffic flow is transmitted only within a trusted network of the service provider. As to be described later, the restricted traffic flow where transmission is performed only within a certain domain is referred as “domain limited flow” in the present specification. In such case, an entity (e.g. HA) belonging to the service provider notifies the mobile node by defining a method to forward the domain limited flow. By the notification of the information, the service provider can control the forwarding of the domain limited flow by the mobile node.
The interface of the mobile node can be shifted (change of connection or changeover of connection) to a different access network. Therefore, the interface of the mobile node may be shifted from a trusted network to a non-trusted network. As to be described below, a network directly managed by a certain service provider or managed by an operator, which is in trust relation, is referred as a trusted network in the present specification, and a network other than the trusted network is referred as a non-trusted network.
However, when it is shifted to the non-trusted network, a network flow profile generated by the service provider may not be updated to the newest information. For instance, in case a domain limited flow is transferred via an interface while the mobile node is moving, the mobile node must make up filter rules relating to the domain limited flow according to a network profile generated by the service provider, and there is a possibility that the domain limited flow may be forwarded to the non-trusted network by referring to a network flow profile, which is not updated.
Specifically, according to the conventional method to notify the flow information from the network side (e.g. from HA) to the mobile node, even after the network where the interface is connected is changed over due to the moving of the mobile node, the mobile node itself cannot correctly decide whether the interface may be continuously used as an interface to transmit and receive a packet relating to the flow. Also, when it is wanted to transmit and receive the flow via the other interface in order to prevent packet loss during the handover, the mobile node itself cannot correctly decide whether or not the flow may be transmitted via the interface that is not specified in the flow information.
To solve this problem, there is a method to use a network trigger that is transmitted before the interface of the mobile node changes over the connection point. For instance, it is supposed here that the mobile node has a 3G (third generation) cellular interface and a WLAN (Wireless Local Area Network) interface, and that these two interfaces are present in a trusted access network.
The access point, to which the WLAN interface is connected, constantly monitors the connection of the WLAN interface. For instance, the access point monitors a threshold level of electric power/signal intensity of the WLAN interface. When the access point detects that electric power/signal intensity from the WLAN interface reaches a value equal to or lower than the threshold level, it is decided that the WLAN interface has moved out of the communication range of the access point. Then, the access point transmits a trigger to the mobile node. This trigger is a “link going down” trigger as used in IEEE 802.21, for instance.
When the mobile node receives a trigger to indicate that WLAN interface is moving out of the communication range of the access point, a method based on the fast mobile IPv6 (FMIPv6) as defined in the Non-Patent Document 4 as given below is carried out, and it is tried to connect to an access point in the vicinity. By using FMIPv6, the mobile node can acquire a new CoA at an access point of the mobile destination of the interface.
The mobile node can transmit a binding update (BU) to update binding entry of the mobile node to HA by using this CoA. When the BU is received, HA checks whether CoA offered from the mobile node is made up by a prefix of the service provider or not.
If HA decides that the mobile node has moved to a non-trusted access network, the network flow profile of the mobile node is updated so that the domain limited flow is transmitted via the interface of the mobile node that is still present in the trusted access network. Then, HA notifies the mobile node to transfer the domain limited flow via HoA/CoA of the 3G interface by updating the network profile of the mobile node, for instance. The updated network profile is transmitted from HA by a binding acknowledgment (BA) to the mobile node.
Instead of the method, by which HA updates the network flow profile of the mobile node, there is a method that the mobile node has the function to update the network flow profile and notifies the change of the network flow profile to HA.
The Patent Document 1 as given below discloses an arrangement of application that is applied to a mobile node having a plurality of interfaces. In this case, the mobile node requests a profile specific to the application to activate the application mounted on the mobile node to the profile server. The profile server prepares or reads a profile specific to the application, and sends the profile specific to the application to the mobile node. Then, the mobile node can interpret this profile specific to the application as a policy rule to carry out selective control of one or more communication interfaces of the mobile node during the operation of the application.
As described above, according to the prior art, when MN registers a plurality of CoA's to HA, MN notifies flow information to HA for the purpose of specifying a CoA used as the transfer destination of the packet to HA. The flow information is to specify the CoA, to which a specific flow transmitted and received by MN is to be transferred. HA selects the transfer destination of the packet to MN according to this flow information notified from MN.
On the other hand, similar flow information can be notifies from HA to MN. In this case, the flow information is generated according to a policy of the network side. When the packet is transmitted, MN selects an interface to be used according to the flow information notified from HA.
[Patent Document 1] U.S. Patent Application Publication No. 2007-0004393
[Non-Patent Document 1] D. Johnson, C. Perkins, and J. Arkko: “Mobility Support in IPv6”; Internet Engineering Task Force, Request for Comments 3775; June 2004.
[Non-Patent Document 2] R. Wakikawa, T. Ernst, and K. Nagami: “Multiple Care-of Addresses Registration”; Monami6 Working Group Internet Draft, Mar. 5, 2007.
[Non-Patent Document 3] H. Soliman, K. ElMalki, and C. Castelluccia: “Flow Bindings in Mobile IPv6 and Nemo Basic Support”; Internet Engineering Task Force Internet Draft; February 2007.
[Non-Patent Document 4] R. Koodli, Editor: “Fast Handovers for Mobile IPv6”; Internet Engineering Task Force Request for Comments 4068; July 2005.
However, in the method to use the network trigger to be received prior to the changeover of the connection point as described above, the access point must have the function to detect connectivity of the interface of the mobile node (i.e. the function to detect cutoff of the connection with the mobile node in advance and to have the trigger). Also, problem may arise that the mobile node should be provided with FMIPv6 for acquiring CoA prior the handover. For instance, in case the access point does not have the function to detect the connectivity of the interface of the mobile node, delay may occur before the mobile node receives the updated network flow profile, and the mobile node may forward the domain limited flow via the non-trusted network because of the delay.
Also, when the electric power and/or signal intensity of the interface of the mobile node changes near the threshold level as defined at the access point, there is a problem in this method that the access point may continuously transmit the network trigger, suggesting the possibility that the link of the interface may be cut off to the mobile node.
As a result, there may arise the problems such as: a problem that a multiple of network triggers may be continuously transmitted from the access point to the mobile node, or a problem that the mobile node may update redundant binding entry according to a multiple of network triggers, and a multiple of the network flow profiles may be transmitted from HA to the mobile node. As a result, the load of the processing in the range of the network or the devices may be consumed uselessly.
According to the technique disclosed in the Patent Document 1, the mobile node selects an interface by referring to the profile specific to the application as stored in the mobile node, but there is no mention on a method to update the profile or a method to change over the interface in case network status have changed due to the handover or to the change of network environment.